Enhancing the pricing Data Model
3 Tasks
1 hr
Scenario
The delivery service application initially used declare Expressions to price and compute the cost of different priceable items, such as business partner membership fees, membership renewal, truck vendor payment, and shipment delivery cost for business partner delivery requests to support the delivery service process. The number of declare Expressions was considered excessive and possibly increased when other priceable items were added, such as varied truck sizes, moving services, and membership types.
Delivery service decided to implement a pricing model approach similar to what is used in e-commerce, or "shopping cart" software. In this approach, developers defined a Pricing data type, which contains the fundamental properties to compute prices. The two most basic pricing models are unit and volume.
Delivery service implemented Rule-Declare-OnChange Rules that react to changes to the inputs to the Pricing data type, eliminating Rule-Declare-Expressions. The solution still depends on Decision tables. Before eliminating the Rule-Declare-Expressions, there was a problem with pricing model-specific Rules at the MDC-Data-Pricing class level. A better design was to use pattern inheritance and polymorphism to move pricing model-specific Rules to their respective classes (for example, MDC-Data-Pricing-Volume). The use of circumstancing as a specialization approach based on the pricing model was rejected early on. The option to use circumstancing for a fine-grained purpose at the MDC-Data-Pricing level, such as the difference between how a price and a cost are computed, was left open.
One reason for wanting to eliminate Decision tables was that to add a new priceable item, the Decision table that specifies the pricing model of the priceable item requires modification. The Decision table that defines how to price the priceable also requires modification, which violates the Open/Closed Principle. Additionally, there was no way to specify that a different pricing model is used for cost compared to prices. MDC COE did not want to add another Decision table; however, MDC COE wanted to eliminate Decision tables.
There was also the problem of passing the inputs to the MDC-Data-Pricing recalculate data transform, setting the value of a corresponding display property, and updating a running total for the total price and cost to compute potential profit.
The MDC COE knows that transitioning from the current state of its "pricing engine" to one that follows the Open/Closed Principle requires analysis. That is where this challenge begins.
The following table provides the credentials you need to complete the challenge:
| Role | User name | Password |
|---|---|---|
| Admin | Admin@deliveryservice | rules |
Detailed Tasks
1 Transition to Pega Live Data
MDC COE was aware that to prevent the overall solution from becoming overly complicated, it had to keep each part of the solution as simple as possible. Complexity increases with every variable that is added.
The Pricing table records historical data. Each column in this table is historical in nature and records what case owns the record (Reference), what the Priceable is, the computed Price, and the inputs used to compute the Price: Quantity, Discount, and PricingModel.
Pricing
|
ItemID (key) |
Reference (key) |
Price |
Quantity |
Discount |
PricingModel |
|---|
The Pricing Decision table was decomposed into a UnitPricing Decision table in the MDC-Data-Pricing-Unit class and a VolumePricing Decision table in the MDC-Data-Pricing-Value class. Polymorphism is applied to a Data Transform called CalculatePricing, which the MDC COE team stubs out in MDC-Data-Pricing and then overrides in each derived class.
The first step is to move the columns in both Decision tables to a live data table. The name of the live data table cannot be Pricing because that name is already in use. A better name for the table is Price because that is the information that the table contains.
Price
|
ItemID |
Quantity From |
Quantity To |
PricingModel |
Price |
|---|
It is possible to say that a Price record has four keys, namely the four columns on the left. If the application uses only two keys (ItemID and PricingModel), it says, Every priceable can have only one row per PricingModel. That does not make sense because Volume pricing requires multiple rows, one for each from/To quantity range. It is impossible to enforce that the system defines only one non-overlapping, contiguous set of volume quantity range rows. Adding an AsOfDate column to this table might allow prices to transition to new values over time smoothly. Because of the complexity of unique key enforcement, the decision is made to auto-generate pyGUID as the primary key by checking the box on the class Rule of the MDC-Data-Price data type.
2 Devise an Open/Closed solution
In Stage 1, devising an Open/Closed solution is straightforward: convert two Decision tables into two live data tables. The next stage is more challenging.
The simplest task is finding an alternative to the InitializeInvoice Data Transform at the beginning of the invoicing stage.
Before discussing this, one might ask, "Why is it necessary to initialize a set of Pricing records? Why not, instead, force the user to build a list of Pricing records using a Table layout, adding one row at a time?" The answer is that it is unnecessary but much more user-friendly and productive if the application initializes Pricing records. If the user must build the initial list of Pricing records themselves every time, they must remember which priceables to begin with and whether they are required or optional. This process might lead to errors. The salesperson should focus on communicating with the customer, not making unnecessary mouse clicks. There is an analogy to ordering food at a restaurant. It is much easier and more practical to have someone select from a menu than ask a server to recite everything on the menu from memory.
The Price property in a Pricing record requires certain inputs. The Discount is initially set to 0, indicating no discount. You can set this in the pyDefault data transform of MDC-Data-Pricing. Multiple applications can initialize the same item. This approach does not restrict what can initialize a Pricing record to an application.
3 Generate invoice UI configuration
When the Item ID, Transaction type, Pricing model, Quantity, and Discount are known, then the application initializes and persists the Invoice to the database and links it with the appropriate Case. A standard Invoice UI is built common across all the transactions (Debit/Credit) and common to all Personas.
Confirm your work
Available in the following mission:
Want to help us improve this content?